This invention relates to a memory management method, and more particularly, to a method of managing a memory in a computer system that uses both a memory area that is managed by a garbage collector and a memory area that is not managed by the garbage collector.
In developing a computer program, memory management such as the allocation/deallocation of a memory area used by the program is one of the laborious tasks that a programmer faces. As a solution to this, a garbage collector is often used.
Java is one of the language processing systems that use a garbage collector to manage a memory. The language specification of Java is equipped with an API for allocating a memory when a program is executed, but not with an API for memory deallocation. A memory area allocated in the process of executing the program is deallocated automatically by a garbage collector installed in a Java virtual machine. A popular mode of memory deallocation processing by a garbage collector (garbage collection, hereinafter abbreviated as “GC”) is to suspend all threads that are being run by the Java program while unnecessary data is collected.
A Java virtual machine activates GC immediately before the consumed amount of a Java heap which stores data generated by the Java program (Java objects) exceeds a certain threshold. However, it is difficult for a user to estimate the consumed amount of the Java heap and to predict when the consumed amount of the Java heap will exceed the threshold. This gives rise to a problem in that the activation of GC suspends the execution of the program irregularly.
As a method of installing GC in a Java virtual machine, generational garbage collection is often employed which uses copy GC requiring a short suspension period in some cases and full GC requiring a long suspension period in other cases. It is, however, difficult in generational garbage collection to predict which of the two types of GC will be activated next time. The resultant problem is that an unexpected activation of GC suspends the execution of the program and consequently lowers the response of the entire system.
Various inventions have been made to solve these problems (see JP 2009-37547 A, F. Pizlo, J. M. Fox, D. Holmes and J. Vitek, Real-Time Java Scoped Memory: Design Patterns and Semantics, In Proceedings of the Seventh IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 2004, and Motoki Obata, Hiroyasu Nishiyama, Masahiko Adachi, Koichi Okada, Takuma Nagase, Kei Nakajima, “Explicit Memory Management in Java”, IPSJ Transactions Vol. 50, No. 7, pp. 1693-1715, July 2009). The documents deal with providing a memory area that is not counted as a target of GC (hereinafter, referred to as “external heap”) in addition to a memory area that is a target of GC (hereinafter, referred to as “Java heap”). An external heap is a memory area that can be managed by the program. The allocation of an external heap, the generation of an object in the external heap, and the deallocation of the external heap are executed in accordance with descriptions written in a source code of the program by the programmer.
F. Pizlo et al, supra discloses putting limitations on data that is generated in an external heap. The limitations are to restrict the generation of data in the external heap referred to from data that is within the Java heap. This guarantees that, when the count of running threads of the program that access data within an external heap becomes 0, automatically deallocating the external heap along with data stored therein does not affect the results of executing the program. In short, an external heap can be deallocated safely with the overhead kept low. If an external heap is deallocated while data within the Java heap is referring to data within an external heap, it means that the reference from the data within the Java heap points to an invalid area (deallocated memory area). Then the execution of the program cannot continue in a normal manner.
However, the technology disclosed in F. Pizlo et al, supra has problems such as the need for a user to program by constantly keeping in mind reference relations between pieces of data, and an increase in program scale or implicit data generation which is not written in the program makes it very difficult to keep track of reference relations in memory areas. Other problems are that whether or not the limitations are violated is not clear until the program is actually executed, the program is not executed in a normal manner in many cases when the limitations are violated causing exceptions, checking details of the limitations at the time of executing the program lowers the performance markedly, and the like.
To solve these problems, JP 2009-37547 A and Motoki Obata et al, supra disclose that an external heap can be used without putting limitations on data that is generated in the external heap. With the technologies disclosed in JP 2009-37547 A and Motoki Obata et al, supra, when deallocating an external heap, reference relations of data within the deallocation target external heap with data within non-deallocation target memory areas (Java heap and non-deallocation target external heaps) are checked and, of the data within the deallocation target external heap, data that is necessary for the subsequent execution of the program is migrated to a non-deallocation target memory area. The deallocation target external heap is thus deallocated while guaranteeing that the deallocation causes no trouble in the subsequent execution of the program. This also allows a user to program by utilizing an API for external heaps without paying attention to data reference relations. The check described above is executed only when an external heap is deallocated, which means that overhead due to conducting the check at other times such as when the program is executed is avoided.
FIG. 1A is a diagram illustrating an example of using a conventional common Java API. A program 201 includes a step 202 of generating “List” class data li and a step 206 of generating “Obj” class data o1 and o2 and letting the data li generated in the step 202 refer to the data o1 and the data o2.
FIG. 1B is a diagram illustrating an example of using a conventional external heap API. A program 203 is a modification of the program 201 of FIG. 1A. This program 203 includes a step 204 of generating an external heap, a step 205 of generating “List” class data li in the generated external heap, the step 206 described above, and a step 207 of deallocating (deleting) the generated external heap. In the step 204, in particular, an external heap is generated by generating “ReferenceExplicitMemory” class data em. In the case where the data within the external heap generated in the step 204 is referred to from data within another memory area, the external heap is deallocated in the step 207 after the data within the external heap is migrated to the other memory area.
Data can be placed in an external heap by two different methods. One method is to put every piece of data generated within one segment of the program in an external heap (see JP 2009-37547 A). The other method is to put data that can be referred to from data associated with an external heap (hereinafter, referred to as “basic point data”) in the external heap (see Motoki Obata et al, supra). The program of FIG. 1B is for using the latter method. In other words, the “List” class data li is associated in the step 205 with the external heap generated in the step 204 on the premise that the latter method is used.
FIG. 2 is a diagram illustrating how data is placed conventionally after a program using an external heap API (see FIG. 1B) is executed. An external heap 110 is generated in the step 204 of FIG. 1B. The “List” class data li generated in the step 205 which is denoted by 301 is placed in the external heap 110 as basic point data. In a Java heap 109 of FIG. 2, on the other hand, the “Obj” class data o1 (302) and the “Obj” class data o2 (303) which are generated in the step 206 and other data F (305) are placed. As indicated by references 304-1 and 304-2, the basic point data li 301 refers to the data o1 (302) and the data o2 (303). The data F 305 refers to the data o1 (302) as indicated by a reference 306.
A case of migrating the data o1 (302) and the data o2 (303) to the external heap 110 is considered. The migration is timed with the execution of GC, a rise in the consumed amount of the Java heap above a certain threshold, or the like.
FIG. 3 is a diagram illustrating how data is placed conventionally after data that can be referred to from basic point data is migrated to an external heap. In FIG. 3, data o1 (401) and data o2 (402) which can be referred to from the basic point data li 301 are migrated to the external heap 110.
If the external heap 110 is deallocated at this point, it means that the reference 306 points to an invalid area (deallocated memory area). The execution of the program cannot continue in a normal manner in this case. Accordingly, when there is a reference from the data F 305 within the non-deallocation target Java heap 109 to the data o1 (401) within the deallocation target external heap 110, the data of (401) is migrated to the Java heap 109 (see FIG. 4).
FIG. 4 is a diagram illustrating how data is placed conventionally when data within a deallocation target external heap is migrated to a non-deallocation target memory area. In FIG. 4, the data o1 (401) is migrated to the Java heap 109 as data o1′ (501). The reference 306 of FIG. 3 is updated as a reference 502 of FIG. 4.
The data o1 (401) and the data o1′ (501) are the same data and the reference 502 is synonymous with the reference 306. In this case, deallocating the external heap 110 along with the data li 301, the data of (401), and the data o2 (402) does not cause a trouble in the subsequent execution of the program.